5.11. Фреймворки

ДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ

Разработчику Архитектору

Фреймворки

Разработка программного обеспечения — это написание кода и организация процессов: управление состоянием, маршрутизация запросов, валидация данных, взаимодействие с хранилищами, обработка ошибок, обеспечение безопасности и многое другое. При отсутствии структурированной поддержки со стороны инструментария разработчик вынужден реализовывать эти задачи вручную, что приводит к дублированию усилий, снижению сопровождаемости и росту риска архитектурных ошибок.

Библиотека вызывается программой, фреймворк управляет программой: он задаёт структуру приложения, определяет точки расширения и инвертирует контроль (Inversion of Control). Это означает, что разработчик пишет код, который встраивается в заранее заданную модель поведения фреймворка, а не наоборот.

Ruby, как язык, изначально ориентирован на выразительность и удобство для человека. Его синтаксис, метапрограммирование, открытые классы и мощная рефлексия позволяют создавать фреймворки, в которых декларативность достигается без избыточной многословности. Это делает Ruby особенно подходящим для построения высокоуровневых фреймворков, где много логики скрывается за простыми DSL (Domain-Specific Language). Именно это свойство позволило Ruby on Rails стать одним из самых влиятельных веб-фреймворков в истории, задав стандарты, принятые позже в других экосистемах.

За два десятилетия сложилась многоуровневая иерархия решений: от полнотелых MVC-стеков до минималистичных инструментов для микросервисов, API и даже консольных приложений. Понимание их различий требует анализа технических характеристик и философии проектирования, целевых сценариев и компромиссов, заложенных в архитектуру.

Далее в главе мы последовательно рассмотрим:

1. Исторический контекст: как возникли Ruby-фреймворки, какие проблемы они решали и как развивалась экосистема.
2. Ruby on Rails — глубокий разбор архитектуры: модель «соглашение вместо конфигурации», компоненты фреймворка (Action Pack, Active Record, Active Support и др.), жизненный цикл запроса, метапрограммирование в основании.
3. Альтернативные веб-фреймворки: Sinatra, Hanami, Roda, Cuba и другие — их место в спектре «мощность vs контроль», различия в подходах к маршрутизации, мидлвару, зависимостям.
4. Фреймворки за пределами веба: для CLI-приложений (например, GLI, Thor), фоновых задач (Sidekiq как часть экосистемы, хотя технически не фреймворк, но требует инфраструктурной поддержки), систем автоматизации.
5. Сравнительный анализ: критерии выбора фреймворка под задачу (размер проекта, команда, требования к производительности, необходимость в гибкости), типичные ошибки при выборе.
6. Эволюция и современное состояние: как менялись фреймворки под влияние новых требований (API-first, микросервисы, асинхронность), роль gems и компонентной архитектуры, совместимость с новыми версиями Ruby (JIT, Ractors, Fibers).
7. Методологические следствия: как фреймворк формирует мышление разработчика, влияет на тестирование, развёртывание, мониторинг и культуру команды.

Начнём с исторического контекста — без него невозможно понять, почему Ruby стал языком, вокруг которого сформировалась одна из самых самобытных экосистем фреймворков.

---

Исторический контекст: от Ruby к Rails и далее

Ruby появился в 1995 году, автор — Юкихиро Мацумото (Matz). Первоначально язык позиционировался как «язык для программистов», делающий процесс разработки приятным. В отличие от Python, где читаемость достигается строгой дисциплиной синтаксиса, или от Java — через явную типизацию и иерархию, Ruby делает ставку на гибкость выражения: методы можно переопределять, классы — расширять во время выполнения, синтаксис допускает множество «естественноречивых» конструкций (5.days.ago, user.admin?, collection.select(&:valid?)).

Эта философия долгое время оставалась преимущественно академической. Прорыв произошёл в 2004 году, когда Дэвид Хайнемейер Хенссон (DHH), разрабатывая инструмент управления проектами Basecamp, выделил ядро повторяющейся логики в отдельный проект — Ruby on Rails.

Rails не был первым веб-фреймворком на Ruby (до него существовали, например, Nitro и IOWA), но он стал первым, кто систематически применил три ключевых принципа:

1. Соглашение вместо конфигурации (Convention over Configuration, CoC). Вместо того чтобы требовать от разработчика явно указывать, где лежат модели, как называются таблицы, какие маршруты использовать, Rails вводит умолчания, основанные на именовании. Например, класс Article автоматически сопоставляется с таблицей articles, контроллер ArticlesController — с маршрутом /articles, метод show в нём — с GET-запросом /articles/:id. Это сокращает объём рутинного кода и ускоряет старт проекта, но требует дисциплины в именовании и понимания принятых соглашений.

2. Не повторяйся (Don’t Repeat Yourself, DRY). Rails предоставляет средства для абстрагирования повторяющейся логики: хелперы, concern-модули, scopes в Active Record, partial-шаблоны. Особенно эффективно это работает в связке с метапрограммированием: например, вызов has_many :comments не просто объявляет ассоциацию — он динамически создаёт методы comments, comments=, comments.build, comments.find и десятки других, адаптированных под контекст.

3. Полный стек «из коробки». Rails включает MVC-ядро, ORM (Active Record), систему маршрутизации (Action Dispatch), шаблонизатор (ERB по умолчанию, но поддержка Slim, Haml), генераторы кода (scaffolding), тестовый фреймворк (изначально Test::Unit, потом Minitest, альтернативно RSpec), средства миграции базы данных, asset pipeline (позже заменённый на Webpacker, потом на jsbundling/cssbundling), фоновые задания (Active Job + адаптеры), почтовые рассылки (Action Mailer), аутентификацию (has_secure_password), защиту от CSRF и XSS по умолчанию. Это позволяет создать работающее веб-приложение буквально за минуты.

Эти принципы обеспечили Rails беспрецедентный рост популярности в середине 2000-х. Twitter, GitHub, Shopify, Basecamp, Hulu — все начинались на Rails. Фреймворк стал своего рода «прототипом современного веб-стека»: многие идеи, впервые реализованные в Rails (миграции базы, RESTful-маршрутизация по умолчанию, asset pipeline, интегрированное тестирование), позже были заимствованы Django, Laravel, ASP.NET MVC и другими.

Однако к концу 2000-х и в начале 2010-х возникли и критические замечания:

• Монолитность и «чёрные ящики». Сложность внутренних механизмов (например, загрузчика классов zeitwerk, системы кэширования ActiveSupport::Cache, жизненного цикла запроса) затрудняла отладку и требовала глубокого погружения.
• Производительность на старте. Хотя сам Ruby (особенно с JRuby или Rubinius) мог быть быстрым, Rails-приложения тратили значительное время на загрузку фреймворка, что мешало использованию в микросервисах или serverless-средах.
• Жёсткая привязка к Active Record. Попытки использовать другие ORM (Sequel, ROM) или даже raw SQL требовали обхода встроенных механизмов, что нарушало принцип DRY.
• Рост сложности конфигурации. Со временем список конфигов (config/*.rb) разрастался, и принцип CoC всё чаще уступал месту явной настройке — особенно при масштабировании.

Эти ограничения породили волну альтернатив, как специализированные инструменты под конкретные задачи:

• Sinatra (2007) — минималистичный DSL для написания веб-приложений. Вместо генераторов и соглашений — одна строчка: get '/hello' { 'Hello World' }. Подходит для микросервисов, API-шлюзов, прототипов.
• Cuba (2010) — ещё более лёгкий вариант, основанный на концепции Rack-приложений как объектов, с акцентом на композицию через мидлвары.
• Roda (2014, от автора Sequel) — фреймворк-«дерево маршрутов», где вложенность определяет логику обработки, а не только HTTP-метод и путь. Позволяет изолировать контекст на уровне поддерева (например, /admin может иметь отдельный набор мидлваров и обработчиков).
• Hanami (первоначально Lotus, 2015) — попытка создать «Rails без компромиссов»: строгая разделённость слоёв (entity, repository, interactor, presenter), отсутствие monkey-patching, поддержка нескольких приложений в одном репозитории (подобно engine в Rails, но с явной границей), внедрение зависимостей «из коробки».

Каждый из этих проектов отвечал на конкретный запрос: «что, если мне не нужен весь Rails, а только часть?», «что, если я хочу контролировать каждую деталь?», «что, если я строю не монолит, а распределённую систему?».

Экосистема Ruby не раскололась. Наоборот, она стала иерархической. Rails остаётся доминирующим решением для full-stack-приложений средней и крупной сложности. Sinatra и Cuba — для лёгких сервисов. Roda — для сложных маршрутизационных сценариев. Hanami — для проектов, где важна архитектурная чистота и долгосрочная поддержка. А фреймворки вроде Trailblazer (надстройка над Rails) или dry-rb (набор микробиблиотек для business-логики) позволяют модернизировать существующие Rails-приложения без полного переписывания.

Эта эволюция отражает общую тенденцию в индустрии: переход от универсальных «платформ» к компонентным, composable-решениям. Ruby, благодаря своей гибкости, оказался особенно приспособлен к такому переходу — без разрушения обратной совместимости и без потери выразительности.

---

Общая структура фреймворка

Ruby on Rails — это набор тесно интегрированных, но логически независимых гемов (gems), каждый из которых решает свою задачу и может использоваться отдельно (хотя и с потерей преимуществ интеграции). Основные компоненты:

• Active Support — расширение стандартной библиотеки Ruby. Предоставляет удобные методы для работы со строками (parameterize, truncate), временем (2.hours.ago, beginning_of_month), хэшами (deep_merge, symbolize_keys), массивами (group_by, index_by), а также инфраструктуру для кэширования, логирования, обработки исключений и локализации. Это основа, на которой строятся все остальные компоненты. Важно понимать: Active Support добавляет функциональность и меняет поведение стандартных классов (String, Hash, Time и др.) через monkey-patching. Это упрощает использование, но требует осторожности при взаимодействии с кодом вне Rails-окружения.

• Active Model — слой, определяющий интерфейс для объектов, которые ведут себя как модели, но не обязательно привязаны к базе данных. Он предоставляет валидации (validates :email, presence: true), сериализацию (as_json), атрибуты с типами (attribute :status, :string, default: 'draft'), а также совместимость с формами (методы errors, persisted?). Любая сущность — будь то объект из внешнего API, конфигурационный параметр или transient-форма — может включить ActiveModel::Model и получить всю инфраструктуру, ожидаемую в Rails-приложении.

• Active Record — ORM (Object-Relational Mapper), реализующий шаблон Active Record (объект = строка в таблице + поведение). Это один из самых обсуждаемых компонентов. Его ключевая идея — согласованность между именованием и структурой. Таблица users → модель User; столбец first_name → метод first_name; внешний ключ author_id → ассоциация belongs_to :author. Active Record автоматически генерирует SQL-запросы, но при этом даёт полный контроль: можно писать raw SQL (find_by_sql), использовать Arel (алгебраический DSL для построения запросов), или заменить адаптер на другой (PostgreSQL, MySQL, SQLite, даже Oracle).
  Важные аспекты:
  — Ленивая загрузка: User.where(active: true) не выполняет запрос, пока не будет вызван метод, требующий результатов (например, to_a, each). Это позволяет строить цепочки (where(...).order(...).limit(...)) без промежуточных запросов.
  — Ассоциации как методы: post.comments не хранит коллекцию, а при первом обращении выполняет запрос, кэширует результат и затем возвращает его. Можно заранее загрузить связи через includes или eager_load, чтобы избежать N+1-проблемы.
  — Callbacks: before_save, after_create и др. — мощный, но опасный инструмент. Их чрезмерное использование приводит к «скрытой» бизнес-логике, трудной для тестирования и отладки. Лучшая практика — использовать callbacks только для технических задач (например, шифрование поля перед сохранением), а бизнес-правила выносить в отдельные сервисы.

• Action Pack — ядро веб-слоя, включающее:
  — Action Controller: базовый класс для контроллеров. Каждый экземпляр обрабатывает один HTTP-запрос. Контроллер получает параметры (params), взаимодействует с моделями, устанавливает переменные для шаблона (@user = User.find(params[:id])), и возвращает ответ через render или redirect_to.
  — Action Dispatch: маршрутизатор, который сопоставляет URL и HTTP-метод с конкретным контроллером и действием (action). Он работает через DSL: resources :articles автоматически генерирует 7 RESTful-маршрутов. Маршруты могут быть вложенными (resources :articles do; resources :comments; end), иметь ограничения (constraints: { id: /\d+/ }), или быть основаны на блоках (get '/search', to: ->(env) { ... }).
  — Action View: система рендеринга шаблонов. Поддерживает ERB (встроенный Ruby), а также сторонние шаблонизаторы (Slim, Haml). Важный механизм — partials (render partial: 'shared/header'), позволяющие повторно использовать фрагменты представлений. Layouts (app/views/layouts/application.html.erb) оборачивают содержимое — это обеспечивает единообразие структуры HTML-документа.
  — Action Mailer: позволяет отправлять электронные письма как обычные контроллеры: есть mailer-класс, методы («действия»), шаблоны (HTML и plain text), и возможность асинхронной отправки через Active Job.

• Active Job — единый интерфейс для фоновых заданий. Он абстрагирует от конкретного адаптера (Sidekiq, Resque, Delayed Job), позволяя писать код один раз и менять бэкенд без переписывания логики. Задача — класс, наследуемый от ApplicationJob, с методом perform. Можно задавать очередь, приоритет, колбэки (before_enqueue, after_perform), повторные попытки.

• Action Cable — интеграция WebSocket в Rails. Позволяет организовать двустороннюю связь в реальном времени (чаты, уведомления, совместное редактирование). Каждое соединение — экземпляр класса ApplicationCable::Connection, каналы (ApplicationCable::Channel) — логические «комнаты», куда подписываются клиенты. Хотя технологически это отдельный процесс (часто требует Redis в качестве бэкенда), с точки зрения разработчика он интегрирован в MVC: можно использовать модели, проверять текущего пользователя и т.п.

• Active Storage — встроенное решение для загрузки и хранения файлов. Поддерживает локальное хранилище и облачные провайдеры (Amazon S3, Google Cloud Storage, Microsoft Azure). Обеспечивает автоматическое создание вариантов изображений (thumbnails), прямые загрузки на облако без прохождения через сервер приложения, и интеграцию с моделями через has_one_attached / has_many_attached.

Эта модульность — не просто техническая деталь. Она означает, что Rails можно настраивать под задачу: отключить Action Cable, если он не нужен; заменить Active Record на Sequel или ROM-RB; использовать только Active Support и Action Pack для API-сервиса. Однако полная сила фреймворка раскрывается при использовании всей системы — именно тогда работает принцип «соглашение вместо конфигурации» во всей полноте.

Жизненный цикл HTTP-запроса в Rails

Чтобы понять, как компоненты взаимодействуют, проследим путь типичного GET-запроса к /articles/42:

1. Запуск Rack-стека. Rails-приложение — это Rack-совместимое приложение (Rack — стандартный интерфейс между веб-сервером и Ruby-приложением). Входная точка — config.ru, который загружает окружение и передаёт управление Rails.application.
   Перед попаданием в контроллер запрос проходит через стек мидлваров (middleware stack), определяемый в config/application.rb. Стандартный стек включает:
   — ActionDispatch::SSL (перенаправление на HTTPS),
   — Rack::Sendfile (отдача статики через веб-сервер),
   — ActionDispatch::Static (отдача файлов из public/),
   — ActionDispatch::Executor (перезагрузка кода в development),
   — ActionDispatch::RequestId (генерация уникального ID запроса для логов),
   — Rails::Rack::Logger (логирование начала и окончания запроса),
   — ActionDispatch::ShowExceptions (перехват необработанных исключений),
   — ActionDispatch::DebugExceptions (вывод трассировки в development),
   — ActionDispatch::RemoteIp (определение реального IP при работе за прокси),
   — ActionDispatch::Reloader (подготовка к перезагрузке в development),
   — ActionDispatch::Callbacks (вызов колбэков to_prepare),
   — ActionDispatch::Cookies и ActionDispatch::Session (обработка кук и сессий).
   Каждый мидлвар — это объект с методом call(env), возвращающий [status, headers, body]. Они образуют цепочку: каждый может модифицировать env, прервать обработку или передать управление дальше.

2. Маршрутизация. Если запрос дошёл до конца стека мидлваров, его получает ActionDispatch::Routing::RouteSet. Он сверяет путь и метод с определёнными в config/routes.rb правилами. Для /articles/42 (GET) совпадает маршрут get '/articles/:id', to: 'articles#show'. В результате определяются:
   — controller: 'articles',
   — action: 'show',
   — params: { 'controller' => 'articles', 'action' => 'show', 'id' => '42' }.
   Эти параметры добавляются в env, и управление передаётся ActionDispatch::Callbacks, который инициирует загрузку требуемых контроллеров и модулей.

3. Инициализация контроллера. Создаётся экземпляр ArticlesController, в него передаются параметры запроса (params), сессия (session), куки (cookies), текущий пользователь (если используется before_action :authenticate_user!), и другие зависимости. Выполняются before_action, around_action и skip_before_action, определённые в контроллере и его предках.

4. Выполнение действия. Вызывается метод show контроллера. Типичная реализация:

   def show
     @article = Article.find(params[:id])
   end

   Здесь происходит:
   — преобразование params[:id] из строки в целое (Active Record делает это автоматически при find),
   — выполнение SQL-запроса SELECT * FROM articles WHERE id = 42,
   — инстанцирование объекта Article,
   — присвоение его переменной экземпляра @article, доступной в шаблоне.

5. Рендеринг представления. Если в действии не вызван render или redirect_to явно, Rails автоматически ищет шаблон по пути app/views/articles/show.html.erb. В шаблоне доступны все переменные экземпляра контроллера (@article), хелперы (link_to, form_with), и локализованные строки (t('.title')). Layout (app/views/layouts/application.html.erb) оборачивает результат рендеринга.

6. Формирование ответа. Результат шаблона преобразуется в строку, упаковывается в объект ActionDispatch::Response, к которому добавляются заголовки (Content-Type, Cache-Control и др.), и возвращается в стек мидлваров — теперь в обратном порядке. Последние мидлвары (например, Rack::ETag, Rack::ConditionalGet) могут модифицировать ответ: добавить ETag, сжать тело (если подключён Rack::Deflater), или заменить статус на 304 Not Modified.

7. Завершение и очистка. После отправки ответа выполняются after_action, обновляются метрики, освобождаются соединения с базой данных (возврат в пул), и логируется итог запроса.

Этот цикл — основа понимания производительности и отладки. Например, медленная загрузка страницы может быть вызвана:
— долгим выполнением мидлвара (например, проверка аутентификации в каждом запросе),
— N+1-запросом в шаблоне (цикл по @article.comments, внутри которого для каждого комментария запрашивается comment.author),
— отсутствием кэширования представления (cache @article do ... end),
— блокировкой базы данных (отсутствие индекса на articles.id — маловероятно, но для других полей — частая ошибка).

---

Альтернативные веб-фреймворки

Экосистема Ruby предлагает Rails и ряд решений, выстроенных вокруг иных приоритетов: максимальная лёгкость, строгая разделённость ответственностей, композиция через мидлвары, минимизация неявных зависимостей. Эти фреймворки решают узкие задачи эффективнее — и при этом формируют у разработчика более глубокое понимание веб-стека в целом.

Все они, как и Rails, построены поверх Rack — стандарта, определяющего единый интерфейс между веб-сервером (Puma, Unicorn, Passenger) и Ruby-приложением. Rack-совместимое приложение — это любой объект, отвечающий на сообщение call(env), где env — хэш с данными запроса (HTTP-метод, путь, заголовки, тело), а возвращаемое значение — тройка [status, headers, body]. Эта простота позволяет легко комбинировать разные слои: мидлвары, маршрутизаторы, контроллеры.

Sinatra

Sinatra (2007) — первый и наиболее известный «микро-фреймворк» в Ruby. Его исходный код умещается в несколько сотен строк, а базовый синтаксис сводится к DSL вида:

get '/hello/:name' do |name|
  "Hello, #{name}!"
end

post '/articles' do
  Article.create(params[:article])
  redirect '/articles'
end

Архитектурные принципы:
— Минимализм: Sinatra не навязывает структуру приложения. Можно писать всё в одном файле (app.rb) или разбивать на модули — выбор остаётся за разработчиком.
— Контекстность: блоки обработчиков (do ... end) выполняются в контексте экземпляра класса Sinatra::Base, что даёт доступ к методам params, request, response, session, cookies, halt, redirect, status, headers. Это упрощает написание, но требует понимания, что self внутри блока — не основной объект приложения.
— Мидлвар-ориентированность: Sinatra сам является мидлваром. Его можно встраивать в существующий Rack-стек (use MyMiddleware; run Sinatra::Application) или использовать как часть крупного приложения (например, как API-эндпоинт внутри Rails-приложения через mount).
— Гибкость рендеринга: поддержка ERB, Haml, Slim, Markdown, JSON «из коробки» через методы erb :template, haml :index, json({ key: 'value' }).

Сильные стороны:
— Быстрый старт: приложение из 5 строк запускается за секунды.
— Низкие накладные расходы: время загрузки — десятки миллисекунд против секунд у Rails. Это критично для serverless-сред (AWS Lambda, Vercel) и микросервисов с холодным стартом.
— Прозрачность: нет «магии» загрузки классов, нет неявных миграций, нет автогенерации кода. Разработчик видит весь поток управления.
— Отлично подходит для:
 • RESTful API фиксированной структуры,
 • webhook-обработчиков (GitHub, Slack, Telegram),
 • внутренних инструментов (админки, скрипты с веб-интерфейсом),
 • прототипирования и MVP.

Ограничения:
— Отсутствие встроенной ORM, системы миграций, генераторов. При росте проекта приходится подключать Sequel/Active Record вручную и настраивать структуру каталогов.
— Нет единой модели для организации бизнес-логики: легко допустить «размазывание» кода по обработчикам.
— Тестирование требует явной настройки окружения (в Rails оно преднастроено).

Практический компромисс: многие команды используют Sinatra + Sequel + RSpec + dotenv + rack-cors как стек для backend-сервисов, где важна скорость и предсказуемость, но не требуется full-stack-функциональность.

Cuba

Cuba (2010) — ещё более радикальный подход к минимализму. Если Sinatra добавляет DSL поверх Rack, то Cuba остаётся в рамках Rack, предлагая лишь удобную обёртку для написания мидлвар-подобных приложений.

Базовая структура:

require 'cuba'

Cuba.define do
  on get do
    on 'hello' do
      on param('name') do |name|
        res.write "Hello, #{name}!"
      end

      on root do
        res.redirect '/hello?name=World'
      end
    end
  end
end

Ключевые особенности:
— Композиция через on: маршрут строится как дерево условий (on get, on 'path', on param(...)). Каждое условие либо совпадает (и передаёт управление внутрь), либо нет (и переходит к следующему блоку). Это обеспечивает явную иерархию и изоляцию контекста.
— Отсутствие глобального состояния: Cuba не модифицирует глобальные переменные, не вводит хелперы верхнего уровня. Всё — через req (request) и res (response).
— Легковесность: исходный код — ~200 строк. Загрузка — < 10 мс.
— Полная совместимость с Rack: Cuba-приложение — это чистый Rack-объект, его можно свободно комбинировать с другими мидлварами (Rack::Builder.new { use Rack::Deflater; run CubaApp }).

Применение:
— Микросервисы с предельно узкой функциональностью (валидация, трансформация, маршрутизация),
— Прокси и шлюзы (например, /api/v1/* → внешний сервис с подменой заголовков),
— Обучение основам Rack и HTTP-обработки (идеален как учебный инструмент).

Отличие от Sinatra: Cuba не стремится быть «удобным» — он стремится быть предсказуемым. Нет автоматического парсинга параметров, нет встроенных методов для редиректов — всё делается явно через req.GET['name'], res.status = 302, res['Location'] = '/'. Это снижает порог входа для понимания, но повышает — для написания.

Roda

Roda (2014), созданный Джереми Эвансом (автором Sequel), — фреймворк, построенный вокруг идеи состояний маршрутизации. В отличие от плоского списка маршрутов (Rails, Sinatra), Roda организует их как дерево, где каждый узел может иметь собственный контекст, мидлвары и переменные.

Пример:

class App < Roda
  route do |r|
    r.root do
      r.redirect '/articles'
    end

    r.on 'articles' do
      r.get Integer do |id|
        @article = Article[id]
        view('articles/show')
      end

      r.post do
        Article.create(r.params['article'])
        r.redirect
      end

      r.is do
        @articles = Article.all
        view('articles/index')
      end
    end
  end
end

Архитектурные инновации:
— Вложенность как изоляция: всё внутри r.on 'articles' работает в своём поддереве. Можно задать мидлвар только для этого поддерева:

r.on 'admin' do
  r.use AdminAuthMiddleware
  # все маршруты ниже будут проходить через аутентификацию
end

— Переменные маршрутизации: захваченные параметры (id в r.get Integer) передаются как аргументы, а не через глобальный params. Это повышает читаемость и уменьшает побочные эффекты.
— Плагины вместо встроенных функций: Roda не включает ничего «по умолчанию». Логирование, сессии, рендеринг шаблонов, JSON — всё подключается через plugin :json, plugin :render, plugin :sessions. Это позволяет собрать ровно тот стек, который нужен.
— Производительность: благодаря компиляции маршрутов в методы класса и отсутствию динамического поиска, Roda часто оказывается быстрее Sinatra и даже некоторых naked-Rack-решений.

Где Roda незаменим:
— Приложения с глубоко вложенными API (/orgs/:org_id/repos/:repo_id/issues/:id/comments), где логично группировать обработку по уровням,
— Многосайтовые системы (multi-tenant), где каждый клиент имеет свой поддомен или префикс пути, и для каждого требуется отдельный набор middleware и настроек,
— Высоконагруженные endpoint-ы, где важна предсказуемость времени отклика.

Hanami

Hanami (2015, изначально Lotus) — попытка создать «Rails без компромиссов» для команд, для которых критична масштабируемость архитектуры и устойчивость к деградации кодовой базы.

Основные принципы:
— Чёткое разделение слоёв (Hexagonal Architecture / Ports & Adapters):
 • Entities — чистые объекты данных (аналог Active Model, но без валидаций),
 • Repositories — абстракция над хранилищем (аналог DAO), инкапсулируют SQL/ORM,
 • Interactors — сервисные объекты, содержащие бизнес-логику (аналог Service Objects в Rails),
 • Actions — контроллеры, которые только обрабатывают HTTP и передают управление Interactor’ам,
 • Views — объекты, отвечающие за подготовку данных для шаблона (никакой логики в шаблонах).
— Отсутствие monkey-patching: Hanami не модифицирует стандартные классы Ruby. Это повышает предсказуемость и совместимость.
— Контейнер зависимостей (Hanami::Container): все компоненты регистрируются явно, их можно заменить на тестовых двойниках без магии.
— Много-приложение в одном репозитории: проект состоит из набора независимых «приложений» (web, api, admin), каждое со своей структурой, зависимостями и middleware. Это облегчает постепенную миграцию и инкрементальное развёртывание.

Структура типичного Hanami-проекта:

apps/
  web/          # основное веб-приложение
    actions/
      articles/
        index.rb
        show.rb
    views/
      articles/
        index.rb
        show.rb
    templates/
      articles/
        index.html.erb
        show.html.erb
  api/          # отдельное API-приложение
lib/
  bookshelf/    # доменная логика
    entities/
      article.rb
    repositories/
      article_repository.rb
    interactors/
      create_article.rb
      list_articles.rb

Преимущества:
— Устойчивость к «разбуханию» контроллеров: бизнес-логика вынесена в Interactors, которые легко тестируются в изоляции.
— Простота замены инфраструктуры: можно заменить ROM-RB на Sequel, или реляционную БД на документ-ориентированную, не затрагивая бизнес-правила.
— Подходит для долгосрочных проектов (5+ лет), где важна поддерживаемость при смене команд.

Сложности:
— Более высокий порог входа: требуется понимание архитектурных паттернов (Repository, Interactor, Dependency Injection),
— Меньше «магии» означает больше явного кода: простое CRUD-действие требует создания Action, Interactor, Repository, View, Template — в Rails это сделал бы scaffold за минуту,
— Меньше готовых решений для специфичных задач (например, интеграция с OAuth требует больше настройки, чем Devise в Rails).

Позиционирование: Hanami — для продуктов, где важна долгосрочная стоимость владения (Total Cost of Ownership). Он популярен в enterprise-средах и в проектах с регулируемыми требованиями к аудиту и документированию.

---

Фреймворки за пределами веба

Хотя веб-разработка остаётся доминирующей сферой применения Ruby, язык изначально позиционировался как инструмент для автоматизации и повседневных задач. Эта традиция сохраняется и развивается — в том числе благодаря специализированным фреймворкам.

CLI-фреймворки

Простой скрипт на Ruby (#!/usr/bin/env ruby) легко превращается в несопровождаемый монолит: опции парсятся вручную (ARGV), ошибки обрабатываются хаотично, help-текст пишется строками. CLI-фреймворки решают эту проблему, предоставляя каркас для создания профессиональных консольных утилит.

Thor (входит в Rails, но используется независимо) — наиболее распространённое решение. Он позволяет объявлять команды и опции декларативно:

class Generator < Thor
  desc "model NAME", "Generates a new model"
  option :migration, type: :boolean, default: true
  def model(name)
    puts "Creating model #{name}"
    if options[:migration]
      puts "  + migration"
    end
  end
end

Generator.start(ARGV)

Вызов ruby generator.rb model User --no-migration автоматически:
— парсит аргументы,
— проверяет типы (--migration → true / --no-migration → false),
— формирует help-вывод по desc,
— изолирует контекст каждой команды.

GLI (Gem-like Interface) — фреймворк для создания gem-подобных утилит (например, bundler, rake). Поддерживает subcommands, global/local опции, конфигурационные файлы (YAML/JSON), интерактивный режим и тестирование через GLI::AppTester.

Применение:
— внутренние devops-инструменты (развёртывание, миграции, резервное копирование),
— генераторы кода (scaffold-альтернативы для не-Rails проектов),
— утилиты для анализа логов, преобразования данных, интеграции с API.

Фоновые процессы и очередь задач

Ruby не имеет встроенного решения для фоновой обработки, но экосистема предлагает проверенные инструменты, которые часто используются в связке с фреймворками.

Sidekiq — наиболее популярный инструмент для асинхронных задач. Хотя технически это не фреймворк (это библиотека + воркер-процесс), он задаёт архитектурные шаблоны:
— задачи — классы с методом perform(*args),
— отправка — MyWorker.perform_async(arg1, arg2),
— обработка — в отдельном процессе, использующем Redis как брокер сообщений.
Sidekiq интегрируется с Active Job (Rails), но может использоваться и автономно (с Sinatra/Roda через sidekiq-client). Его преимущества — простота, производительность (многопоточность на основе threads, не процессов), веб-интерфейс для мониторинга.

Sucker Punch — альтернатива для случаев, где внешняя зависимость (Redis) нежелательна. Задачи выполняются в том же процессе, что и веб-приложение, в отдельных потоках. Подходит для малонагруженных задач в небольших приложениях, но не масштабируется и не обеспечивает durability.

Shoryuken — клиент для Amazon SQS, позволяющий использовать облачные очереди без Redis. Актуален при развёртывании в AWS.

Ключевой принцип: фоновая обработка — часть архитектуры, а не опциональное дополнение. Даже в Sinatra-приложении стоит проектировать задачи так, чтобы их можно было легко перенести в очередь — это повышает отзывчивость API и упрощает масштабирование.

Автоматизация и скриптовые фреймворки

Для задач, не требующих веб-интерфейса или CLI (например, ежедневная обработка файлов, синхронизация с внешними системами), Ruby предлагает решения на стыке библиотек и фреймворков.

Rake — встроенный инструмент для определения и запуска задач (tasks), аналог Make, но на Ruby. Задачи объявляются в Rakefile:

task :backup do
  sh "pg_dump mydb > backup.sql"
end

task :deploy => :backup do
  sh "scp backup.sql server:/backups/"
end

Вызов rake deploy выполнит backup, затем deploy. Rake поддерживает зависимости, параметры (rake deploy[prod]), и namespace’ы (namespace :db do; task :migrate; end → rake db:migrate). Используется везде — от Rails-миграций до CI/CD-пайплайнов.

Whenever — DSL для генерации cron-заданий из Ruby-кода:

every 1.day, at: '4:30 am' do
  runner "BackupJob.perform_later"
end

На этапе деплоя whenever --update-crontab обновляет системный crontab, обеспечивая синхронизацию расписания с кодом.

---

Критерии выбора фреймворка

Выбор фреймворка — стратегическая задача. Ниже — система критериев, применимая независимо от размера команды или бюджета.

Критерий	Rails	Sinatra	Roda	Hanami
Скорость MVP	⭐⭐⭐⭐⭐ (scaffold, generators)	⭐⭐⭐⭐ (5 строк — рабочий endpoint)	⭐⭐⭐ (требуется настройка плагинов)	⭐ (много шагов даже для hello world)
Долгосрочная сопровождаемость	⭐⭐⭐ (при дисциплине)	⭐⭐ (требует явной архитектуры)	⭐⭐⭐⭐ (чёткая изоляция)	⭐⭐⭐⭐⭐ (слои, DI, тестирование)
Производительность старта	~1–3 с	~50–100 мс	~20–50 мс	~300–800 мс
Гибкость архитектуры	⭐⭐ (жёсткая привязка к Active Record)	⭐⭐⭐⭐⭐ (выбор за вами)	⭐⭐⭐⭐ (плагины, дерево маршрутов)	⭐⭐⭐⭐ (слои, адаптеры)
Глубина документации и сообщества	⭐⭐⭐⭐⭐ (тысячи гайдов, Stack Overflow)	⭐⭐⭐⭐ (хорошо документирован)	⭐⭐ (меньше примеров)	⭐⭐⭐ (активное, но небольшое)
Интеграция с legacy-кодом	Сложно (требует изоляции)	Легко (встраивается как мидлвар)	Легко	Умеренно (требует адаптации слоёв)

Эмпирические правила:

1. Если срок — 2 недели, а функционал — CRUD + аутентификация → Rails.
2. Если endpoint должен обрабатывать 10 000 RPS с задержкой < 50 мс → Roda + Falcon (асинхронный сервер) + Sequel.
3. Если проект рассчитан на 10+ лет и регулярную смену команд → Hanami или Rails с жёстким соблюдением архитектурных boundary (например, через Trailblazer или dry-rb).
4. Если задача — один webhook или простой конвертер данных → Sinatra или даже naked Rack.

Нет «лучшего» фреймворка — есть «наиболее подходящий» под контекст. Опытный разработчик на Ruby свободно перемещается между ними, выбирая инструмент под задачу, а не наоборот.

---

Эволюция под влиянием современных требований

Экосистема Ruby адаптируется к новым реалиям, не отказываясь от своих принципов.

API-first и клиент-серверная декомпозиция

С ростом популярности SPA (React, Vue, Svelte) и мобильных клиентов, backend всё чаще выступает как поставщик данных, а не генератор HTML. Это повлияло на фреймворки:

• Rails представил rails new --api, отключающий middleware, view-слои и asset pipeline, оставляя только Action Controller, Active Record и сериализацию (через ActiveModel::Serializers или Jbuilder).
• Grape — DSL-фреймворк специально для REST/GraphQL API, с автоматической валидацией параметров, версионированием и OpenAPI-документацией. Часто используется как часть Rails-приложения (mount Grape::API => '/api').
• Hanami изначально проектировался как API-friendly: Actions возвращают JSON по умолчанию, Views — чистые сериализаторы.

Асинхронность и event-driven архитектура

Ruby 3.0+ ввёл Fibers с планировщиком Fiber.scheduler, позволив писать асинхронный код в синхронном стиле. Серверы Falcon и Iodine поддерживают async/await на уровне I/O (БД, HTTP-вызовы, файлы). Это меняет расчёты:

• Раньше: Sidekiq для фоновых задач + синхронный веб-сервер.
• Теперь: Falcon может обрабатывать 10 000+ соединений в одном процессе, вызывая async def show и делая await Article.find_async(id) без блокировки.

Фреймворки адаптируются:

• Rails 7.1+ добавил поддержку async в контроллерах (через ActionController::API),
• Roda имеет плагин :async,
• dry-rb разрабатывает асинхронные версии своих компонентов.

Serverless и контейнеризация

Требования к быстрому холодному старту и низкому потреблению памяти подстёгнули развитие:

• Jets — фреймворк для развёртывания Ruby-кода на AWS Lambda,
• Praxis — специализированный API-фреймворк с фокусом на контракты (design-first),
• Container-оптимизация: использование zeitwerk (загрузчик классов Rails) в standalone-режиме, отключение ненужных гемов через Bundler.require(:default, :production).

---

Методологические и организационные следствия

Фреймворк — не просто инструмент. Он формирует:
— Мышление разработчика: Rails учит «думать ресурсами» (REST), Hanami — «думать границами», Sinatra — «думать запросами».
— Культуру тестирования: в Rails принято писать feature-тесты (системные), в Hanami — unit-тесты на Interactors, в Roda — интеграционные на уровне маршрутов.
— Подход к развёртыванию: Rails-приложения традиционно развёртываются как монолиты (Capistrano, Docker), Hanami — как набор сервисов (Kubernetes, Helm), Sinatra — как функции (AWS Lambda, Cloudflare Workers).
— Требования к документированию: в Rails многое подразумевается (CoC), в Hanami — всё должно быть явно задокументировано (DI, адаптеры).

Команда, выбирающая фреймворк, выбирает и модель взаимодействия. Это требует осознанности:

• Не навязывайте Hanami начинающим разработчикам — это вызовет сопротивление и ошибки,
• Не используйте Rails для high-frequency trading — это будет борьба с природой фреймворка,
• Не стройте микросервисную архитектуру на 100 одинаковых Rails-монолитах — это illusion of decomposition.

---